feat(spp_mis_demo_v2): add child/spouse/other membership types#165
feat(spp_mis_demo_v2): add child/spouse/other membership types#165
Conversation
Enable the child, spouse, and other group-membership-type vocabulary codes inside the demo module and apply them when generating households. The existing blueprint roles already honor gender and age ranges, so the generator assigns membership types from those roles: head -> head spouse -> spouse child -> child adult, elderly -> other Fix a stale reference to spp_registry.group_membership_kind_child in the add_member change-request demo data; point it to the new xmlid. The types are scoped to spp_mis_demo_v2 (not spp_vocabulary) so that core stays non-prescriptive about household composition.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 19.0 #165 +/- ##
==========================================
+ Coverage 71.45% 71.61% +0.16%
==========================================
Files 932 933 +1
Lines 54792 55318 +526
==========================================
+ Hits 39152 39618 +466
- Misses 15640 15700 +60
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Code Review
This pull request introduces structured membership types (head, spouse, child, and other) for household members within the demo data generator. Key changes include the definition of new vocabulary codes, updates to the mis_demo_generator and seeded_volume_generator to assign these types based on member roles, and the addition of a test case to verify correct assignment and basic business logic. One improvement was suggested to use the modern Odoo Command helper instead of legacy tuple syntax for Many2many field operations in the seeded volume generator.
|
|
||
| type_id = self._get_membership_type_id(type_code) | ||
| if type_id: | ||
| mval["membership_type_ids"] = [(4, type_id)] |
Why is this change needed?
OpenProject #922 —
spp_mis_demo_v2should populategroup-membership-typeon every household membership so the demo data realistically exercises the vocabulary. Before this change, onlyheadwas assigned; spouse/adult/child members had no type at all, and a demo change-request referenced a non-existent xmlid (spp_registry.group_membership_kind_child).How was the change implemented?
New demo vocabulary data —
spp_mis_demo_v2/data/vocabulary_group_membership_type.xmlregisterschild,spouse,othercodes against the existingvocab_group_membership_typevocabulary. Scoped to the demo module (notspp_vocabulary) so core stays non-prescriptive about household composition.Blueprint roles drive type assignment. The existing story blueprints and seeded blueprints already encode demographically-correct gender and age ranges (child ≤ 17 in most cases, adult spouse opposite-gender to head, etc.). The generator just maps role → membership type:
headheadspousespousechildchildadult,elderlyotherseeded_volume_generator.py— replaced_get_head_type_idwith a cached_get_membership_type_id(code); assigns per-role.mis_demo_generator.py— applies the mapping in_create_household_membersfor spouse, adults, and children (head already had it); also fixed the stale xmlid on thecarlos_elena_moralesadd_member demo change request.New unit tests
test_non_head_members_have_membership_types— asserts every generated membership carries exactly one of{head, spouse, child, other}, at most one spouse per household, andchildmembers are younger than the head.Unit tests executed by the author
Full
spp_mis_demo_v2suite (270 tests, Docker): 0 failed on my changes. The only errors (3) are pre-existingtest_claim169_demoFK issues onres_partner_bank, unrelated to this PR.How to test manually
spp_mis_demo_v2on a fresh DB.Head, optionally oneSpouse, zero or moreChild, with the rest asOther.Related links